The notion of a system has been around for several decades. For instance, in Ackoff's 1971 paper “Towards a System of Systems Concepts” (Management Science, 17 (July) 661-671), definitions of several key systems concepts are provided. A system is defined as “ . . . a set of interrelated elements”, the state of a system is defined as “ . . . the set of relevant properties which that system has at [a moment of] time” and the environment of a system is defined as “ . . . a set of elements and their relevant properties, which elements are not part of the system but a change in any of which can produce a change in the state of the system”. Also, an event is defined as “ . . . a change in the . . . state of the system (or environment)” and the paper describes the dependency of systems changes on events in the system or its environment, through “reactions”, “responses” and “autonomous acts”.
One way in which a modern system could be illustrated is given in FIG. 1. At its core is a product 1-2, such as a general purpose computer system or an embedded computer system. The product 1-2, which is also a system within the wider system of FIG. 1, may be employed as an actor in an enterprise 1-1 (which may also be viewed as a kind of system) in the provision of a service 1-3 such as online technical support. The service 1-3 constitutes another system. Products 1-2 and/or services 1-3 can be consumed by other enterprises (not shown) or by consumers 1-4, e.g. a person 1-5, a group 1-6 or a household 1-7. The consumer 1-4 may also be modelled as a system.
Enterprises 1-1 and consumers 1-4 are socio-technical systems, and services 1-3 are usually delivered through a combination of technology and human resources. This means that in analysing, designing, constructing, testing, implementing and operating modern complex, adaptive systems, it is desirable to address more than just the technical requirements of computers and other machinery. For maximum effect, it is important to understand how industrial and other processes interact with applications and how people are organised to execute the processes of these applications.
The tools which have developed over the last fifty or so years are in many ways inadequately equipped to address the challenges of modern systems, such as the system described above. The inventor considers that this is because: their underlying architectures are essentially sequential or serial in nature, whereas most real-world systems are highly parallel or concurrent; they typically have static definitions, which makes them difficult to adapt as real-world systems change over time; they reinforce semantic gaps between different layers of architecture and different stages of development; and because different disciplines use different languages and tools for very similar phenomena, inhibiting the sharing of solutions, particularly in complex, socio-technical systems. It is as a consequence of this last point in particular that prior art concerning the analysis, design, construction, testing, implementation and operation of modern complex, adaptive technical and socio-technical systems of the types described in FIG. 1 comes from many existing fields. These fields include: sequential and parallel computer hardware, including synchronous and asynchronous sequential circuits; computer software, including event-driven software; data (including “triggers”) and meta-data; computer operating systems; artificially intelligent agents, including expert systems; system development methodologies, tools and techniques; analytic simulators and digital virtual environments; and business process re-engineering and Organisation design.
FIG. 2 represents a conventional Von Neumann computer. It contains a Central Processing Unit (CPU) 2-3, which contains a Control Unit 2-4 and an Arithmetic & Logic Unit (ALU) 2-5. The computer also contains a Memory 2-6, and an Input/Output (I/O) Controller 2-2. The CPU 2-3, the Memory 2-6 and the I/O Controller 2-2 communicate via an internal Bus 2-1. The fetch, decode, execute cycle of such a computer is operated under the control of a Program Counter 2-7, included in the CPU 2-4. By default, the Program Counter 2-7 increments after each instruction, so the next action obtained is the next instruction in sequence. Exceptions (or jumps) in the flow of sequence can be effected by an instruction overwriting the Program Counter 2-7 with the address of the next instruction to be executed. (This control flow mechanism appears to have several features in common with the Turing Machine, proposed by Alan Turing in 1936. While it is likely that John Von Neumann was aware of Turing's ideas, it is not clear whether he applied them in the Report to the U.S. Army Ordnance Department, entitled “Preliminary Discussion of the Logical Design of an Electronic Computing Instrument”, which he presented in 1946 along with A. P. Burks and H. H. Goldstine.)
The resulting “flow & jump” mechanism enables Von Neumann-like computers to support a vast range of computational algorithms. However, most of the applications supported by today's and tomorrow's computers are very different to the computations required a few decades ago to break codes or to predict missile trajectory. Instead, they need to reflect the systems in the world around us, either to help us manage the complexity we experience or to use that complexity to increase the sophistication of our products and services. In these real-world systems, many simultaneous or near simultaneous events may need to be recognised, stored and potentially acted upon. Our models of these systems also change continuously as our understanding of the systems develops.
Similarly, the current proliferation of computing devices was not predicted in Von Neumann's time. At that time, it was expected the potential for such devices would be restricted to scientific and military applications, and that there would perhaps some hundreds of computers at most. However, there are now hundreds of millions Von Neumann type computers, both general purpose (e.g. desktop computers) and embedded (e.g. automotive control systems). Many of these devices also communicate with one another, usually through somewhat rigidly defined computer networks. In the near future, it is envisaged that there will be billions of “computers” cooperating with one another through networks which dynamically configure and reconfigure themselves second-by-second. The inventor considers that the Von Neumann architecture will become a major inhibitor to the development of such massively dynamic computer networks.
The Von Neumann architecture, which is the basis for the vast majority of modern computers, is fundamentally sequential. “Communicating Sequential Process” (CSP), “Dataflow” and “Actor” models have been proposed in attempts at providing concurrency. However, these approaches tend to reinforce semantic gaps, to support only coarse-grained parallelism or to be limited to relatively specialised computational applications.
Communicating Sequential Processes was devised by Professor C. A. R. Hoare (“Communicating Sequential Processes”, Communications of the ACM, vol. 21, pages 666-677, 1978), building on the work of Dijkstra (DIJKSTRA, E. W. (1975). “Guarded Commands, Nondeterminacy and Formal Derivation of Programs”, Communications of the ACM, vol. 18, pages 453-457). Communicating Sequential Processes introduced parallel sequential processes capable of communicating via synchronised input and output commands. Initial work in this area was targeted at new programming languages, but has since been taken up in hardware designs, for example in Inmos's Transputer.
Another alternative to the Von Neumann architecture is the “Dataflow” machine, which can be contrasted with the Von Neumann “control-flow” approach. In Dataflow machines, the program counter has been eliminated and execution is driven solely by the availability of operands. This enables much more fine-grained parallelism than either the Von Neumann or Communicating Sequential Process models.
FIG. 3 illustrates an early Dataflow processor designed by Dennis and Misunas at MIT in 1975. The MIT Dataflow Machine includes a set of Processing Elements 3-1, which are interconnected through a Communication Network 3-2. Within a Processing Element 3-1, an Activity Store 3-5 holds activity templates. An Instruction Queue 3-4 holds the addresses of fired instructions (i.e. activity templates for which all inputs are available). The first entry in the Instruction Queue 3-4 is removed by a Fetch Unit 3-9, which uses the entry to fetch the corresponding opcode, data, and destination list which constitute the activity template held in the Activity Store 3-5. This is then packed into an operation token, which is forwarded by the Fetch Unit 3-9 to an available Operation Unit 3-3. The operand slot in the template then is cleared. The Operation Unit 3-3 executes the operation specified by the opcode using the corresponding operands, generates result tokens for each destination, and provides them to a Send Unit 3-8, which decides whether the destination of the token is in a local Processing Element 3-1, or is in a remote one. If the destination is determined to be local, the token is sent to a local Receive Unit 3-7 that, in turn, passes it to an Update Unit 3-6. Otherwise, the token is routed to the destination Processing Element 3-1 through the Communication Network 3-2. Instructions are processed in a pipeline fashion since all units operate concurrently.
The Dataflow approach has been described (by AGHA, GUL “Actors: A Model of Concurrent Computation in Distributed Systems”, MIT Press, 1986) as having a static interconnection topology, since functions are queued in advance and are initiated based on pre-determined token-matching rules, which are the only events that the Dataflow model recognises. Token matching adds considerably to the complexity of the approach, which has consumed much of the development effort associated with Dataflow machines. This limits the Dataflow model's range of solutions to those involving computation, as well as limiting its capacity to support dynamic execution of models which can be extended or reconfigured.
Dataflow and control-flow approaches have been combined (e.g. in the design for the Intel Pentium Pro (COLWELL, R. P., STECK, R. L. “A 0.6 μm BiCMOS Processor with Dynamic Execution”, In: Proceedings of the International Solid State Circuits Conference, February 1995)) in an attempt to tackle the weaknesses of both approaches. However, this has not fundamentally addressed the limitations inherent in either approach.
Yet another alternative to the Von Neumann architecture is the “Actor” model of concurrent computation, originally devised by C. E. Hewitt and others in the late 1970's and described by Gul Agha in “Actors: A Model of Concurrent Computation in Distributed Systems”, MIT Press, 1986. In this model, actors are stimulated by the receipt of a “communication” contained within a “task” to enact a pre-defined “behaviour” with which the actor has been associated. Behaviours are defined as collections of, possibly conditional, “commands” which will cause the actor to create other actors and/or send further communications, as well as potentially modifying its own behaviour in response to the next communication it may receive. The only type of event which actor systems recognise is the creation of a new “task” (i.e. “communication”). Hence, all activity within an actor system is driven by the propagation of communications between actors. This is both a strength and a weakness of actor systems. These relatively simple mechanisms can be used to embody a vast range of concurrent computations. It is claimed that the Actor model is powerful enough to implement any system which can be defined within the Communicating Sequential Process or Dataflow models described above. However, it limits the degree of granularity of concurrency to individual behaviours, each of which may include multiple, conditional commands. It can also be said that the Actor model widens the semantic gap between modern systemic applications and the underlying computational environment, such as requiring convoluted mechanisms for handling non-communication related events, thereby limiting its real-world application.
Underlying most Von Neumann and other existing computer architectures are “synchronous sequential” electronic circuits. In such circuits, transitions between states are initiated by pulses from a clock. For example, each step in the fetch-execute cycle described above is triggered by a single clock pulse. This approach is recognised to have certain drawbacks, including inhibiting cycle time reduction, unnecessary power dissipation and unfortunate noise and emission side-effects. As a consequence of these drawbacks, in recent years there has been considerable interest in exploiting asynchronous sequential circuits, despite the more complex design and testing requirements of such circuits. However, this research, carried below the level of the overall computer architecture, has not addressed the underlying sequential nature of the Von Neumann architecture.
The conventional high-level languages in which most software is written developed from the need to make the machine languages which controlled Von Neumann type computers more accessible. As such, these languages embody the limitations of the sequential machines. This has been described by Silc et al (SILC, JURIJ; ROBIC, BORUT; UNGERER, THEO “Processor Architecture: From Dataflow to Superscalar and Beyond”, Springer, 1999) who said “ . . . the architectural characteristics of the Von Neumann design are still valid due to the sequential high-level programming languages that are used today and that originate in the Von Neumann architecture paradigm.”
As illustrated in FIG. 4, conventional software is written as a program in some programming language (e.g. C, Java, etc.). Every instruction of each program then needs to be translated either into the machine language of the computer on which the program is to be executed, or into some intermediate form (e.g. “bytecode”) to be executed on a virtual machine (VM). In this latter case, individual operations then become micro-programs (which are also serial) at the next level down.
It should be noted here that much modern software is designed and developed using an “object-oriented” (OO) approach. Having been developed out of the Hewitt Actor approach described above, OO software exploits the sending of messages between “objects” to drive program execution. This is particularly evident in the development of graphical user interface (GUI) software, which is often described as “event-driven”. Such “coarse-grained” events initiate the execution of small segments of software, usually referred to as “methods” in the OO prior art. However, such software segments remain firmly rooted in the Von Neumann paradigm—i.e. they are essentially sequential. (The name “actor” employed by Hewitt et al is much more appropriate than “object”, since such components effect action within the software. However, it is the term “object” which, although confusing, has gained currency in the prior art.)
Similarly, “triggers” have recently been introduced within the database management system (DBMS) domain, in which a small piece of software is associated with a particular field within the database and is executed whenever the associated field is updated. Again, while this has some elements of coarse-grained event-driven processing, each small piece of software is itself firmly rooted in the Von Neumann paradigm.
Several event-driven, object-oriented approaches are described in the prior art, including Pavilion (WO2001/77872), Cook et al (U.S. Pat. No. 6,178,432) and Mukherjee et al (U.S. Pat. No. 6,195,685), as well as IBM Technical Disclosure Bulletin NN9511431 “Event Data Management in an Object Oriented System”. Each of these is a variety of the coarse-grained event-driven approach described above, and as such relies on sequential software (usually OO “methods”) for implementation.
Considering how computer hardware and software interact, FIG. 5 shows how a modern layered computer operating system might be designed, similar to that described in TANENBAUM, ANDREW S. “Modern Operating Systems” Prentice Hall, 2001. A computer operating system manages the underlying computer hardware resources (e.g. memory, disks, printers, etc.) and provides a “virtual machine” more suitable to the needs of the users and programmers of the computer system concerned. It comprises seven virtual layers, 5-11 to 5-17 running on a CPU 5-20. The first layer 5-11 hides the underlying hardware, providing a low-level virtual machine on top of which a common operating system can be designed to support several different hardware configurations. The second layer 5-12 provides the basic building blocks of the operating system, including interrupt handling, context switching and memory management. The third layer 5-13 contains the components essential to managing processes, and, more specifically, threads, within the operating system, which is essential to providing a multiprocessing environment on essentially a single, sequential CPU. The fourth layer 5-14 provides the drivers which handle all activity involving each of the specific peripherals or resources which are or which may be connected to the CPU. Above this is the virtual memory management layer 5-15, which enables the computer to offer memory spaces to its users which are apparently significantly in excess of the physical memory available. The sixth layer 5-16 provides the features necessary to support the management of files held on disks and other long term storage media. The seventh and top layer 5-17 handles system calls and thereby provides the interface through which user programs 5-18 can make calls on the system resources.
All these layers of software components reside in layers above the computer's CPU 5-20, requiring the CPU 5-20 to be involved in every operation which the computer performs. Some approaches have been devised to share this workload between multiple CPUs, through multi-processor (tightly coupled), multi-computer and distributed computer (loosely coupled) configurations. However, due to the monolithic, sequential nature of the underlying hardware model, these configurations add significant complexity to the supporting operating system, proportional to the tightness of coupling, particularly in the areas of process scheduling and synchronisation.
In recent years, there has been a considerable increase in the awareness of the importance of understanding meta-data, which can be thought of as “data about data”. This increased awareness seems to have come from two main sources, namely: the need to realise the value of data warehousing and business intelligence solutions; and the need to reduce the effort associated with developing, maintaining and exchanging information between websites. Consequently, there has been growing interest in the software communities in technologies such as XML and the Meta-Object Framework (MOF). The value of meta-data in the realm of data interchange is well understood. However, in most cases, the meta-data is not available to users or their applications, being either implicit in the application, or held in analysis and design phase models which have not been translated through to the ultimate application. This inhibits the flexibility of most such applications to adapt as the context in which they are being used changes.
Similarly, there have also been developments in the area of meta-level programming, specifically with the use of Metaobject Protocols (MOPs) employed by the Common LISP Object System (CLOS) and other programming languages and systems. These MOPs involve base level application programming in the context of meta-level programs which describe the objects in the programming language or system itself. However, such MOPs are only available to specialist programmers during development and are not available for modification at run time—i.e. post compilation or interpretation. They also appear to add considerably to the complexity of execution, making it difficult for them to support concurrent execution in particular.
Other meta-data related prior art includes Nye (US2003/0195867). Nye claims to provide “a way to flexibly handle state transitions by using an event model”. It defines an event as “a set of actions, possibly empty, which is optionally contingent upon a condition” and states that “during each tick of the internal clock, all computable events are processed in random order.” In this way, it uses meta-data to guide the operation of a conventional coarse-grained event-driven system.
Conventional organisation design can begin with either a functional approach (marketing, sales, manufacturing, engineering, finance, IT, etc.), or a process-based approach (e.g. as employed in Activity Based Costing) or a value-chain approach (as described by Porter (PORTER, MICHAEL E. “Competitive Strategy”, Free Press, 1980)) or some combination of these approaches (e.g. matrix organisation). More systemic approaches to understanding and/or designing “soft systems” have been described recently (e.g. Peter Checkland “Systems Thinking, Systems Practice”, John Wiley & Sons, 1981), and these have sometimes been employed in the process of organisation design. In each case, however, what the organisation has to do is assumed to be fixed once the re-organisation is complete and the result is a static functional, process-based or matrix organisation.
Considerable interest has been given in recent years to learning organisations, but definitions are somewhat imprecise. For example, it has been suggested that a learning organisation is designed as a flat, non-hierarchical structure with minimal formalized controls, but this gives no clues as to what components should be included in the structure.
Stafford Beer in his book “Diagnosing the System for Organizations” (Chichester: John Wiley & Sons, 1985), introduced the concept of a “viable system”, which he defined as a system “ . . . able to maintain a separate existence . . . [within] a particular sort of environment”. In this book, Beer identified the need for organisations (which he saw as systems) to become more adaptable if they are to remain viable, but did not describe the detailed mechanisms by which adaptation occurs and did not pay particular attention to how such viable organisations are enabled.
The concept of an artificial intelligent agent has been around since before the birth of computing. During the 1960's and 1970's, considerable attention was paid to making computers “intelligent”. In particular, Expert Systems found a niche within which they had a recognisable technical effect, for example in the configuration of computer hardware such as in Digital Equipment Corporation's “R1” system. However, such agents have found limited sustained commercial value, due to their complexity and to the cost of building them. They also typically have poor run time performance. The mechanisms by which they could become viable (in the sense discussed by Beer) have not been described.
FIG. 6 shows a general model of learning agents, as defined by RUSSELL, STUART AND NORVIG, PETER “Artificial Intelligence: A Modern Approach”, Prentice-Hall, 1995. An agent 6-0 takes performance standards and inputs from an environment, and acts on the environment. In the agent 6-0, a performance element 6-1 takes percepts as inputs from sensors 6-2 and decides on actions, which it then outputs to effectors 6-3. A learning element 6-4 takes some knowledge about the performance element 6-1 together with input from a critic 6-5 concerning how the agent is performing, and determines what changes to send to the performance element 6-1 with a view to improving performance for the future. A problem generator 6-6 suggests actions to the performance element 6-1 that will lead to new and informative experiences, based on learning goals provided from the learning element 6-4.
In Expert Systems and other knowledge-based systems, the performance element 6-1 often comprises knowledge in the form of “IF <condition> THEN <inference>” rules, known as “production rules”. Such systems use these rules together with “forward-chaining” search algorithms to find inferences from which actions can be initiated and from which, sometimes, new “knowledge” can be generated. While Expert Systems have had some considerable technical effect and commercial success, as did the R1 system described above, production rules were found to have poor performance, due to the resources consumed by forward chaining search algorithms, and limited application. Consequently, designers often had to resort to other methods to capture knowledge, such as frame systems and neural networks. As a result, several different knowledge representation mechanisms, which are difficult to integrate, can be present in modern-day knowledge-based systems.
Some prior art, including Koninklijke KPN (WO2002/054296 & EP1253533) and Ross (U.S. Pat. No. 6,598,033) claim to employ knowledge-based approaches in solving domain-specific problems—telecommunication service provision and alarm correlation respectively. However, these owe more to conventional object-oriented approaches, as described earlier, than to knowledge-based systems.
Several modelling techniques have been used to describe rule systems of different types.
Computer software has been described and/or designed using several graphic techniques from conventional flow charts, such as those shown in FIG. 7, to object-oriented techniques, such as those described in the Unified Modelling Language (UML)—and associated languages, such as the Object Constraint Language (OCL). UML is illustrated by the UML class diagram and the UML activity diagrams of FIGS. 8A and 8B respectively. Mathematical set theory has also been employed, through languages such as “Z”.
Computer hardware has traditionally been modelled graphically using block diagrams or electronic circuit diagrams. More recently, the Very High Definition Language (VDHL) has been employed to model, and subsequently simulate, the structure and behaviour of hardware components and systems using software-like rules.
Industrial and other processes have typically been described and/or designed using conventional flow charts, like those used by software designers. These flow charts often form the basis of modern-day workflow solutions. Processes have also been described and/or designed by dedicated process modelling techniques, such as those of IDEF0 and IDEF3 shown in FIGS. 8C and 8D respectively.
The fact that the techniques employed in designing organisations, processes, software and hardware are different is a significant issue since it can be difficult to describe and/or design systems which span these different domains. On the other hand, they do have many features in common. They are also incomplete since not all rules concerned with the behaviour of the system can be captured. For example, it may be noted that OCL was required as an add-on to UML to capture many of the constraints needed to describe a business system adequately. Also, these techniques basically are flow-based or sequential. IDEF0 and UML claim not to be flow-based descriptions of systems, but to get to a complete description of behaviour, flow-based or sequential components are required. Specifically, these components are IDEF3 process flows for IDEF0 and Methods for UML. While Z models are not flow based, they have no mechanisms for describing event-driven systems. Because they are not built into the solution system, these techniques typically are disconnected from the final system. Lastly, these techniques do not allow meta-objects to be modelled easily alongside objects, which limits their ability to support adaptive behaviour.
Several process templates (or “methodologies”) have been proposed for developing the technical and/or socio-technical systems described in FIG. 1. These are typically of a “waterfall” style, such as the Information Engineering Methodology shown in FIG. 9A, or of an “iterative” style, which might be employed in an Object-Oriented Methodology, such as that shown in FIG. 9B. In both cases, these methodologies define the sometimes repeated but always sequential order in which the development processes should be executed if such systems are to be defined correctly. Neither approach recognises or adequately reflects the real-world situation in which several activities either can or must proceed in parallel for any such development to complete successfully.
In his book “The Fifth Discipline: The Art & Practice of The Learning Organization” (1990, London, Century Business) Peter Senge distinguishes between two types of complexity associated with systems, namely: “detail complexity” and “dynamic complexity”. Detail complexity is the complexity of “many variables” and is well known to software developers and business process modellers who have tried to capture precise rules within their models. Dynamic complexity on the other hand is the complexity of “non-obvious consequences” where unforeseen interactions between elements of a system have unexpected effects, particularly over time. Testing detail complexity is the domain of conventional software testing environments, in which repeatable test cases are created to validate that a particular program or system does what it is expected to do under specific test conditions. The role of simulation is to explore dynamic complexity.
Simulators can be considered to be from one of two classes. These are: analytic simulators, which are used to understand the dynamics of a whole system, usually while it is being designed, constructed or modified; and digital virtual environments, which are used to enable humans to interact with complex virtual systems, typically in a gaming or training situation.
Focusing on analytic simulators, Zeigler et al (ZIEGLER, BERNARD P.; PRAEHOFER, HERBERT; KIM, TAN GON “Theory of Modelling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems”, Academic Press, 1999) have shown that there are essentially three ways in which a system can be modelled: as a continuous system described by differential equations (Differential Equation System Specification—DESS); as a collection of equations showing the state of the system after each discrete period of time (Discrete Time System Specification—DTSS); or as a collection of equations describing how the system state changes from one discrete event to another (Discrete Event System Simulation—DEVS). As DEVS simulators can be described for quantised DESS models and for DTSS (see Zeigler et al 1999), DEVS may be considered as the key to the three system modelling methods.
DEVS models system dynamics through sets of equations representing: a set of input values, each associated with an external event; a set of states; a set of output values; an internal state transition function; an external state transition function; an output function; and a resting time function. The only events recognised by such simulations are the passage of a pre-determined period (i.e. the resting time) constituting an internal event, or the arrival of an input, constituting an external event. Although these internal and external events cause activity within such a simulation, this is as a coarse-grained trigger to a state transition function, which typically is implemented as a sequential program or method within an object-oriented programming language. There is no facility within such simulation models to have activity triggered by an internal change of state, other than the passage of time.
In Parallel & Distributed System Simulation (PDES—see FUJIMOTO, RICHARD M. “Parallel and Distributed Simulation Systems”, John Wiley & Sons, 2000), parallel and distributed simulation models can be described in terms of collections of DEVS simulators. PDES typically offers coarse-grained parallelism (concurrency is achieved through assigning separate sequential logical processes to different processors). The fundamental difference between parallel and distributed simulations is communication latency between “logical processes” in the simulation. It should be noted that there are different kinds of time involved in a simulation, namely physical time, simulation time and wall-clock time and that these are particularly important for PDES. Physical time is the time in the physical system being simulated. Simulation time is an abstraction of the physical time employed by the simulation, which typically is speeding up (although it may be slowing down) physical time to meet the needs of the simulation. Wall-clock time is the actual time during the execution of the simulation, and is particularly important for distributed simulations.
Although several classes of analytic simulators and digital virtual environments have been defined for both single processor and multi-processor (i.e. parallel and distributed) architectures, such simulations are defined in terms of sequential state transition functions which must be defined separately from the detailed rules of a new or changing system, thereby separating any simulation from the main design stream and constraining it to coarse-grained parallelism at best; this may be one of the reasons why simulation is used relatively infrequently despite the large paybacks often claimed for simulation projects.
The prior art contains applications of such simulators, such as Borschev et al (“Distributed Simulation of Hybrid Systems with AnyLogic and HLA”, XP00434823PD), which employs a coarse-grained, event-driven, object-oriented approach, as well as potential solutions to some of the challenges of parallel or distributed simulation described elsewhere (e.g. Steinman—U.S. Pat. No. 6,324,495).
Some of the key constraining characteristics of the above-described prior art follow.
The Von Neumann Architecture has embedded the “flow & jump” mechanism in virtually all current computing solutions. This has helped to reinforce a sequential/serial view of the world. Even some of the more popular attempts at defining a concurrent computation model (e.g. CSP) have been constrained by this viewpoint, limiting the granularity of the parallelism which they have been able to achieve.
As hardware and software designers have worked to make computers more usable, two critical semantic gaps have been introduced. The first is the gap which has developed between high-level languages and the underlying computer hardware as hardware designers have attempted to work around the limitations of the Von Neumann Architecture with techniques such as pipelining. The second is the gap between the problem domain and the software, which has become more acute as the nature of the problem has adapted from being one of computation to one of system representation.
Several schemes described in the prior art have adopted a coarse-grained, event-driven and usually object-oriented approach. However, these are constrained both by the variety of definitions of “events”, “states”, “actions” and “objects” and by their reliance on Von Neumann-based sequential software segments (usually OO “methods”) for implementation.
Most of the tools in use today to understand and design systems tend to be unsatisfactory since they do not allow the designing-in of the ability to adapt as understanding of the subject system changes. Consequently, change is resisted and, when it finally becomes inevitable, it can be traumatic. For example, much money is spent each year on IT projects which fail.
The interactions between different components of systems are often overlooked because they are addressed by people from different disciplines who have different tools (such as different modelling techniques) for looking at their component of the situation. Many IT project failures are caused by failing to recognise the “people change management” implications of a particular technical solution, primarily because application developers and change management specialists lack the tools and language to help them understand others' points of view.
The invention provides several related concepts many of which individually, and in combination, create a common, holistic framework, potentially enabling parallel execution of adaptable rule sets and eliminating the semantic gaps between problem domains and software and hardware solutions. Taken together, these concepts offer a new approach to the analysis, design, construction, testing, implementation and operation of complex technical and socio-technical systems in general and of adaptive, massively micro-parallel computing systems, of self-adaptive viable intelligent agents and of viable enterprises in particular.